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7  APRIL  1997 


MEMORANDUM  FOR  JOINT  MODELING  AND  SIMULATION  SYSTEM  (JMASS) 

SENIOR  STEERING  GROUP  (SSG)  MEMBERS 

SUBJECT:  Joint  Initial  Requirements  Document  (JIRD) 


Attached  is  the  result  of  over  a  year's  worth  of  effort  on 
the  part  of  your  representatives  on  the  JMASS  Implementation  Team 
to  develop  a  baseline  requirements  document  for  a  Modeling  and 
Simulation  (M&S)  system  that  supports  the  acquisition  process. 

The  JIRD  represents  the  Team' s  best  understanding  of  the  initial 
overall  programmatic  requirements,  high  level  capabilities,  and 
operational  and  support  requirements  for  JMASS  at  this  point  in 
time  and  their  effort  is  to  be  applauded. 

It  is  also  understood  that  these  are  "initial"  requirements 
which  need  to  be  evolved  and  tested  through  Pilot  Projects  which 
have  been  designated  by  the  Steering  Group.  This  process  will 
lead  to  a  more  fully  defined  set  of  requirements  that  will  be 
documented  in  a  Joint  Requirements  Document  which  will  be 

•  Fully  coordinated  throughout  the  acquisition  community, 

•  Presented  to  the  EXCIMS  for  approval,  and 

•  Implemented  by  a  Joint  Program  Office  or  similar 
management  structure  to  oversee  the  development  of  the 
required  system  including  a  potential  commercial-of f-the 
shelf  procurement. 

The  signatures  appearing  in  the  JIRD  represent  a  commitment 
on  the  part  of  the  Senior  Steering  Group  members  to  work  together 
during  the  next  year  to  achieve  this  objective. 


SIGNED 


Patricia  Sanders 
Director,  Test,  Systems 
Engineering  and  Evaluation 
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Joint  Modeling  and  Simulation  System  (JMASS) 
Joint  Initial  Requirements  Document  (JIRD) 


Background 

The  Joint  Modeling  and  Simulation  System  (JMASS)  requirements  will  evolve 
through  multiple  stages.  The  purpose  of  this  document  is  to  define  the  initial  overall 
programmatic  requirements,  high  level  capabilities,  operation  and  support  requirements  for 
JMASS.  Pilot  Projects  will  be  used  to  refine  and  further  specify  the  requirements  in  this 
document.  Implementation  of  the  specific  requirements  will  be  accomplished  by  a  Program 
Office. 

1 .  General  Description  of  Operational  Capability 

JMASS  is  designed  to  support  acquisition  as  defined  in  the  Department  of  Defense 
(DoD)  Regulation  5000.2-R.'  JMASS  provides  a  software  architecture  for  the  development 
of  models,  configuration  of  models  into  simulations,  execution  of  simulations,  and  post 
processing  of  data  obtained  from  the  simulation.  The  JMASS  software  facilitates 
interoperability  with  other  simulations  in  accordance  with  DoD  accepted  standards. 
Additionally,  it  defines  and  implements  a  set  of  standards  and  documentation  for  JMASS 
compliant  models.  It  provides  tools  that  assist  in  the  development  and  application  of  reusable 
models  and  model  components.  Standards  defined  and  implemented  by  JMASS  shall  include: 

•  Guidelines  for  the  development  of  JMASS  compliant  models  and  documentation. 

These  guidelines  are  called  the  Software  Structural  Model  (SSM)^’^ 

•  Tools  to  implement  the  SSM 

•  Model-to-model  and  model-to-system  interfaces 

•  Tool-to-system  interfaces 

•  Guidelines  and  tools  for  porting  legacy  models  to  JMASS 

•  Man-machine  interface  modeling 

The  Joint  Simulation  System  (JSIMS)  and  Joint  Warfare  System  (JWARS)  will  build 
models  and  simulations  and  foster  interoperability  and  reuse  of  models  from  the 
mission/battle  through  campaign/threat  level.  JMASS  will  help  build  models  and  simulations 
and  foster  interoperability  and  reuse  of  models  from  the  subsystem/component  through  the 
engagement/system  level  (Figure  1).  The  High  Level  Architecture  (HLA)'*  is  chartered  to 
foster  interoperability  and  reuse  of  simulations  across  the  modeling  and  simulation  (M&S) 
spectrum  (i.e.,  subsystem,  system,  mission,  theater). 

In  addition,  JMASS  provides  a  Modeling  and  Simulation  Reuse  Library  of  JMASS 
compliant  models  as  well  as  related  documentation  and  data. 


2.  Threat.  Not  applicable. 
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Figure  1.  Assessment  of  Current  Demand  for  JMASS 


3.  Shortcomings  of  Existing  Systems 

There  is  no  current  process  within  the  DoD  which  provides  affordable  tools  to  conduct 
requisite  performance  and  engineering  analysis  in  a  timely  manner  for  the  purpose  of 
determining  performance  requirements  analysis,  system  functional  analysis,  and 
implementation  detail  cost  tradeoff  analysis  within  a  total  force  context  and  throughout  the 
life  cycle  of  a  program.  Current  DoD  and  Service  modeling  and  simulation  approaches  have 
been  independently  developed  and  maintained  around  specific  warfare  areas  and  platforms 
which  precludes  transfer  of  information  or  integration  of  results  in  an  aggregate  force  level 
analysis.  This  results  in  a  very  costly  and  time  consuming  process  of  patching  models  to 
models  and  simulations  to  simulations  which  do  not  reflect  the  actual  behavior  of  defense 
systems.  Current  models  cannot  account  for  full  spectrum  environmental  effects  on  sensor 
performance  which  dominate  complex  weapon  system  performance. 

Every  DoD  activity  and  Service  activity  has  been  required  to  independently  develop 
the  entire  software  communications  infrastructure  layer  to  allow  their  program  specific 
questions  to  be  adequately  addressed.  This  has  resulted  in  independent  approaches  to: 

•  the  run  time  environment  for  the  execution  of  models  and  simulations 

•  the  interfaces  between  model  to  model  and  from  acquisition  phase  to  acquisition 
phase  with  little  reuse  possible 
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•  database  design  and  accessibility 

•  tools  to  build  application  specific  models  and  simulations 

•  the  definition  of  operational  and  physical  world  frames  of  reference 

Due  to  the  absence  of  standards  there  are  many  duplicative  model  development  efforts, 
particularly  in  the  area  of  threat  systems  and  environmental  representation. 

4.  Capabilities  Required 

A.  Required  JMASS  Functional  Capabilities 

These  required  JMASS  fimctional  capabilities  will  provide  a  model 
development  and  simulation  system  to  support  JMASS  users  in  the 
development  and  maintenance  of  object-oriented  models  and  simulations, 
configuration  of  different  scenarios,  setup  and  execution  of  simulation,  and 
analysis  of  results. 

JMASS  shall: 

(1 )  Provide  tools  to  support  computer  aided  development  and  maintenance 
of  object-oriented  models  of  systems  and  environments  for  use  in  the  following 
activities: 

•  operations  analysis 

•  concept  formulation 

•  engineering  discipline  specific  analysis 

•  total  ownership  cost  analysis 

•  design  and  construction  analysis 

•  test  planning  and  performance  prediction  analysis 

•  maintenance  and  operations  analysis 

•  manufacturing  and  process  flow  analysis 

(a)  Establish  standards  for  developing  JMASS  compliant  models 
and  associated  documentation. 

(b)  Support  computer  aided  development  and  maintenance  of 
component/subsystem  and  engagement/system  level  models  of 
complex  systems. 

(c)  Permit  the  capability  to  operate  and  interoperate  at  both  the 
engagement/system  and  component/subsystem  levels. 

(d)  Provide  guidelines  and  tools  for  porting  legacy  models  to 
JMASS. 
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(e)  Support  computer  aided  development  and  maintenance  of 
environmental  models  which  are  representative  of  the  actual 
operational  and  physical  environment  that  a  system  under  investigation 
is  expected  to  operate  in.  JMASS  must  allow  models  that  address  the 
full  spectrum  of  the  physical  environment.  Specifically,  the 
bathymetry,  hydrography,  sea-air  interface,  terrain,  meteorology, 
atmosphere,  and  exoatmosphere  must  be  able  to  be  represented. 

(f)  Provide  the  ability  to  use  commercial-off-the-shelf  (COTS)  and 
existing  government  tools  to  develop  models  and  to  process  data. 

(g)  Provide  ability  to  selectively  execute  language  specific  and 
operating  system  software  debugging  tools  including  software  traps, 
stepped  execution,  tracing,  and  output  during  runtime  without 
perturbing  other  models,  players,  or  general  simulation  execution. 

(2)  Provide  tools  to  configure  system  and  environment  models  and 
appropriate  data  to  create  synchronized  simulations  of  operational  scenarios. 
This  synchronization  shall  provide: 

(a)  Tools  to  assist  users  in  entering  parametric  data,  to  include 
initial  conditions,  defaults  values  for  reusable  components,  scenario 
definition  via  tabular  and  graphical  means,  visual  placement  of  objects 
in  the  simulation,  and  all  necessary  steps  required  to  begin  a  simulation. 

(b)  An  efficient  and  flexible  simulation  time/event  synchronization 
function  that  supports  faster  than  real-time  digital  simulations;  real¬ 
time  simulations,  including  operator-in-the-loop,  hardware-in-the-loop, 
tactical  systems,  and  live  assets;  and  slower  than  real-time  simulations. 
Provide  capability  to  accept  online,  real-time  inputs  to  dynamically 
alter  controllable  variables.  Provide  the  data  from  simulations  as  on¬ 
line,  real-time  outputs  to  system(s)  under  test. 

(3)  Provide  tools  to  execute  simulations  and  gather  performance  data  for 
the  piupose  of  analysis  and  visualization  of  the  results. 

(a)  Implement  the  following  simulation  control  functions:  start, 
pause,  restart,  terminate,  and  vary  the  time  standard.  Provide  the 
capability  to  access  the  current  simulation  state  during  a  pause. 

(b)  Provide  accurate  data  time  tagging  and  a  repeatable,  controlled 
time/event  synchronization  with  precise  linear  relationships  between 
the  system  clock,  model  execution  and  data  transfers. 
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(c)  The  inclusion  of  objects  and  models  into  a  simulation  and  the 
removal  of  objects  and  models  from  a  simulation  shall  be  capable  of 
being  accomplished  dynamically,  on-line  during  the  simulation 
execution  as  well  as  offline.  Whether  performed  on-line  or  offline,  the 
inclusion  or  removal  of  objects  and  models  shall  be  automatically 
accommodated  by  the  operating  system  and  structure  of  JMASS  and 
shall  not  require  any  manned  software  modification  or  recompiles. 

(d)  Provide  the  user  the  capability  to  monitor  the  simulation  and 
individual  model  behavior  during  simulation  runtime. 

(4)  Provide  tools  or  interfaces  to  legacy  tools  to  support  computer  aided 
data  visualization,  data  analysis  and  evaluation  of  simulation  results  for  the 
following  purposes: 

•  operations  analysis 

•  concept  formulation 

•  engineering  discipline  specific  analysis 

•  total  ownership  cost  analysis 

•  design  and  construction  analysis 

•  test  planning  and  performance  prediction  analysis 

•  maintenance  and  operations  analysis 

•  manufacturing  and  process  flow  analysis 

(a)  Desired  end  products  include  engineering  graphs,  tables,  maps, 
traces  of  actual  versus  predicted  value,  position,  animation,  etc. 
Interface  standards  and  object  model  templates  will  be  specified  for 
tool  sets. 

(b)  Provide  the  ability  to  use  COTS  and  existing  government  tools 
to  develop  models  and  to  process  data. 

(5)  Provide  a  non-proprietary  evolutionary  support  infrastructure  which 
will  insure  flexibility,  openness  and  minimal  constraints  to  users.  This 
infrastructure  shall  be  designed  to  isolate  the  impact  of  changes  to  the  system. 
Required  capabilities  are  grouped  into  three  areas:  (a)  underlying  technologies 
associated  with  high  performance  computing,  processing,  displays,  and 
peripherals;  (b)  primitive  support  services  linking  users  to  the  hardware  run 
time  environment;  and  (c)  operational  support  services  which  isolate  the  user 
from  the  mimdane  system  alignment  tasks  thereby  freeing  him  or  her  to 
concentrate  on  the  tasks  of  building,  executing,  and  analyzing  complex 
simulations. 
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(a)  Underlying  technologies 

(i)  JMASS  shall  be  capable  of  being  hosted  on  high  end 
personal  computers,  workstations  and  high  performance 
computers. 

(ii)  Provide  a  capability  to  support  rapid  exchange  of  high 
volumes  of  information,  and  support  servicing  of  priority  data 
transfers  between  locally  distributed  systems. 

(b)  Primitive  support  services 

(i)  The  development  tools  and  the  supporting  JMASS 
software  will  be  unclassified.  JMASS  shall  include  a  security 
package  such  that  all  models  and  data  are  appropriately  marked. 

(ii)  Notify  operator  of  exception  conditions  and  faults 
asserted  during  a  simulation  (e.g.,  hardware  malfunction). 
Support  domain  specific/user  defined  exception  handlers  to 
service  exception  conditions  and  hardware  faults  asserted  during 
a  run. 

(iii)  Provide  tools  to  support  defining  and  establishing 
interfaces  among  models  within  a  simulation  and  between  the 
system  infrastructure  and  the  models.  Support  message  and 
data  passing  over  distributed  heterogeneous  networks  with 
minimal  latency.  Have  interface  standards  that  enable  insertion 
of  new  technologies.  These  standards  shall  use  or  provide 
compatibility  with  industry  or  DoD  standards  for 
communications  between  model  objects.  Perform  all  necessary 
data  conditioning  to  make  the  data  movement  and  storage 
transparent  to  the  object  models. 

(iv)  Coordinate  and  synchronize  data  traffic  between  objects 
and  support  objects  with  different  update  rates.  JMASS  will 
permit  variability  of  synchronization  tolerances  or  different  data 
rates. 

(v)  As  part  of  the  JMASS  installation  procedures,  JMASS 
shall  sense  network  parameters  which  are  critical  to  successful 
installation.  Incompatibilities  shall  be  flagged  and  presented  to 
the  installer. 
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(vi)  Confirm,  prior  to  simulation  start,  that  all  software  and 
hardware  is  ready  to  begin  simulation. 

(vii)  The  human  computer  interface  shall  include  graphic 
interfaces. 

(viii)  JMASS  shall  provide  tools  for  data  management. 

(c)  Operational  support  services 

(i)  Support  use  of  COTS  tools  to  assist  in  software 
configuration  management  of  models. 

(ii)  Provide  the  ability  to  configure,  execute,  and  analyze  the 
results  of  statistical  simulations. 

(iii)  Provide  the  capability  to  wrap  legacy  models. 

(iv)  Support  multimedia  publication  services  for  the  purpose 
of  demonstration  and  report  generation. 

(v)  Provide  an  evolution  of  the  system  to  insure  that  objects 
built  to  prior  releases  remain  viable  and  are  compatible  with 
existing  releases.  When  capability  can  not  be  maintained, 
conversion  tools  shall  be  provided. 

(6)  Provide  computer  aided  verification  and  validation  methods  and  tools 
for  new  models  and  simulations  developed  within  the  JMASS. 

(7)  Provide  a  Modeling  and  Simulation  Reuse  library  of  JMASS  compliant 
models  as  well  as  related  documentation  and  data. 

(a)  Provide  an  interface  with  the  DoD  Modeling  and  Simulation 
Resource  Repository. 

(b)  Support  COTS  tools  to  assist  in  libr3iry  management. 

(8)  Provide  on-line  computer  assisted  help  routines  as  well  as  on-line  user 
documentation  to  facilitate  training  and  operator  assistance. 

B.  Logistics  and  Readiness.  Not  applicable. 

C.  Other  System  Characteristics.  Not  applicable. 
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5.  Program  Support 

A.  Software  and  Documentation  Maintenance 

This  system  shall  be  used  in  many  geographically  dispersed  sites  and  shall 
require  a  central  support  activity  to  provide  publishing,  distribution  and  maintenance 
services  and  support.  Maintenance  will  address  only  those  portions  of  JMASS  that 
have  been  developed  by  the  JMASS  Program  or  provided  to  users  of  JMASS  by  the 
JMASS  Program  Office.  These  items  include  off-line  development;  configuration, 
and  post  processing  tools;  on-line  data  logging  and  analysis  tools;  and  simulation 
control. 

B.  Support  Equipment  and  Software 

No  special  support  equipment  nor  software  shall  be  required. 

C.  Human  Systems  Integration 

(1)  Provide  a  user-fiiendly  Human  Computer  Interface. 

(2)  Tutorials,  on-line  references,  manuals,  and  context  sensitive  help 

screens,  to  include  all  system  configuration,  operations  and  maintenance,  shall 
be  available  to  assist  operators  for  those  tasks  which  are  not  easily  handled 
intuitively. 

(3)  Develop  and  maintain  on-line  as  continuously  available  soft  copy,  a 
users  manual  and  complete  set  of  all  documentation. 

D.  Computer  Resources 

(1)  Open  Systems  Architecture  and  Standards 

JMASS  shall  have  an  open  systems  architecture  using  industry  or  DoD 
standards.  It  shall  operate  on  and  be  portable  between  workstations. 

(2)  Hardware 

(a)  JMASS  software  shall  be  transportable  and  shall  be  capable  of 
being  hosted  on  high  end  personal  computers,  workstations,  and  high 
performance  computers. 

(b)  Support  multiprocessor  operations  for  a  single  team  or  a  single 
player. 
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(3)  Software 

(a)  Software  shall  be  developed  and  maintained  according  to  the 
practices  delineated  by  the  Software  Engineering  Institute.^’^ 

(b)  Software  shall  be  tested  in  accordance  with  DoD  5000.2-R 

E.  Other  Logistics  Considerations.  Not  applicable. 

F.  Command,  Control,  Commimications,  Computers  and  Intelligence.  Not 
applicable. 

G.  Transportation  and  Basing.  Not  applicable. 

H.  Standardization,  Interoperability,  and  Commonality 

JMASS  shall  be  fully  compliant  with  appropriate  versions  of 
Distributed  Interactive  Simulation  (DIS)  and  HLA. 

I.  Mapping,  Charting,  and  Geodesy  Support.  Not  applicable. 

J.  Environmental  Support.  Not  applicable. 

6.  Force  Structure.  Not  applicable. 

7.  Schedule  Considerations 

To  be  determined.  Services  to  provide  initial  operational  capability  and  final 
operational  capability  criteria  based  on  pilot  projects. 
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ABBREVIATIONS 


AOA 

Analysis  of  Alternatives 

COTS 

Commercial-off-the-shelf 

DoD 

Department  of  Defense 

DIS 

Distributed  Interactive  Simulation 

HLA 

High  Level  Architecture 

JIRD 

Joint  Initial  Requirements  Document 

JMASS 

Joint  Modeling  and  Simulation  System 

JSIMS 

Joint  Simulation  System 

JWARS 

Joint  Warfare  System 

M&S 

Modeling  and  simulation 

SSM 

Software  Structural  Model 
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GLOSSARY 

Cell  A  cell  is  a  set  of  simulation  entities  using  fully  consistent  databases  and 

simulations,  i.e.,  the  simulation  models  have  been  specifically  designed  to 
work  together.  All  entities  within  a  cell  must  have  unrestricted  broadcast 
of  datagram  messages  to  all  other  entities  within  the  cell.  By  definition, 
the  entities  in  a  cell  are  homogeneous,  and  at  the  same  security 
classification  level.  For  example,  a  set  of  intercormected  SIMNET 
simulators  using  the  same  terrain  database  constitute  a  cell.  A  cell  is 
usually  located  on  a  single  local  network,  but  it  is  possible  to  distribute 
one  over  a  wide  area  network  if  sufficient  bandwidth  is  available  and 
latency  is  low  enough  to  maintain  coherency.  If  any  type  of  interface  is 
required  to  network  with  a  remote  site,  the  two  sites  are  different  cells. 
[DMSO  Glossary  of  M&S  Terms] 

Component  Any  model  object.  A  component  may  have  more  than  one  subcomponent. 

Fidelity  (1)  The  similarity,  both  physical  and  functional,  between  the  simulation 
and  that  which  it  simulates. 

(2)  A  measure  of  the  realism  of  a  simulation. 

(3)  The  degree  to  which  the  representation  within  a  simulation  is  similar  to 
a  real  world  object,  feature,  or  condition  in  a  measurable  or  perceivable 
manner.  [DMSO  Glossary  of  M&S  Terms] 

High  Performance  Computers 

Machines  with  computational  capabilities  in  MIPS  or  MEGAFLOPS 
equivalent  to  a  1990  model  Cray. 

Open  System  A  system  in  which  the  components  and  their  composition  are  specified  in 
a  non-proprietary  environment,  enabling  competing  organizations  to  use 
these  standard  components  to  build  competitive  systems.  There  are  three 
perspectives  on  open  systems:  portability  -  the  degree  to  which  a  system 
component  can  be  used  in  various  environments,  interoperability  -  the 
ability  of  individual  components  to  exchange  information,  and  integration 
-  the  consistency  of  the  various  human-machine  interfaces  between  an 
individual  and  all  hardware  and  software  in  the  system.  [DMSO  Glossary 
of  M&S  Terms] 

Player  A  player  is  a  special  type  of  component;  it  is  the  smallest  component 

recognizable  during  run  time  as  an  independent  object  by  the  executive. 

Proprietary  A  system  where  the  interfaces  do  not  meet  open  system  standards,  i.e.  the 
specifications  of  the  interfaces  are  exclusively  owned  by  a  private 
individual  or  corporation  under  a  trademark  or  patent,  the  use  of  which 
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would  require  a  license.  [Variation  based  on  Proprietary  Specification  in 
Open  System- JTF  TOR,  Nov  1995] 

Site  (1)  An  actual  physical  location  at  a  specific  geographic  area,  e.g.,  the  Ft. 

Knox  Close  Combat  Test  Bed  (CCTB)  which  can  contain  a  single  cell, 
multiple  cells,  or  only  part  of  a  cell.  (2)  A  node  on  the  Distributed 
Interactive  Simulation  (DIS)  long  haul  network  which  can  contain  a  single 
cell,  multiple  cells,  or  only  part  of  a  cell.  (3)  A  level  of  configuration 
authority  within  a  DIS  exercise.  [DMSO  Glossary  of  M&S  Terms] 

Team  A  grouping  of  players  executed  as  a  single  UNIX  process. 
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